1. Field of the Invention
The invention relates to apparatus and accompanying methods for use therein for implementing a secure, cost-effective, web-enabled, integrated, virtual office user environment, through a centralized server(s), through which a remotely stationed user can access typical office network-based applications, including, e.g., e-mail, file sharing and hosted thin-client application programs, through a remotely located network, e.g., WAN, connected web browser, as well as for remotely providing network monitoring and management capabilities through a centralized administrative web site. The present invention is particularly, though not exclusively, suited for use in small to medium size organizations which, for economic reasons, do not have adequate in-house computer support (technical and administrative) capabilities.
2. Description of the Prior Art
With laptop personal computers (PCs) having become rather ubiquitous over the last several years, individuals who are away from their office, typically desktop, PCs and hence not in communication with their office networks, because they are either traveling or are at home, often have a continuing need to gain access to those networks. Such access is required if, for no other reasons, than only for those users to transfer files between their laptop PCs and servers on these networks and/or access their network-based e-mail servers (both for receiving incoming and transmitting outgoing messages).
This need is not only shared by many individuals but also by organizations of widely varying size, from large organizations to very small businesses and other groups.
The art teaches various approaches to meet this need. However, they are all deficient in one respect or another. In that regard, none of these approaches offers an effective, integrated solution that readily provides all the functionality obtainable using an office network through one simple remote user interface, such as a web browser.
Specifically, one approach is to simply install appropriate conventional communications software in each client laptop PC and permit its user to access, through a dial-up telephone line, his(her) office network to gain access to the network server for file transfer and e-mail are functionality. All application programs would reside on and locally execute on the client laptop PC. While this approach is quite simple, nevertheless it necessitates that each and every such application program be installed, configured and then maintained on that PC. Consequently, over time, this approach, particularly in view of the on-going support costs of the installed application programs, can become quite expensive.
Another approach involves using a traditional virtual private network (VPN) to provide wide area network (WAN) connectivity from a user's remote or home location to an office local area network (LAN). A VPN WAN connection implements a so-called OSI layer 2 extension or “conduit” of the office network itself between the LAN and the user's remote/home location. A remote client PC, connected through a VPN to an office LAN, locally appears on the LAN, as far as that user is concerned, as if that client PC were directly connected to it. In essence, for packets destined from the client PC to the LAN, a VPN connection therebetween involves, at a near end of the VPN connection, encapsulating outgoing OSI layer 3 packets at the client PC into layer 2 IP (Internet protocol) packets and transmitting those layer 2 packets over the VPN connection (in effect tunneling those layer 3 packets through the VPN connection), and subsequently, at a remote (LAN) end of the VPN connection, disassembling the layer 2 packets to yield the layer 3 packets and applying the resulting layer 3 packets onto the LAN for carriage to their ultimate destination, such as a network server. The opposite operation occurs in reverse for packets emanating from LAN, e.g., the server, and destined, over the VPN connection, to the remote client PC. Since the layer 2 packet tunneling is totally transparent to both the LAN and the client PC, advantageously the client PC can provide the same level of functionality to its user as if that PC were directly connected to the LAN.
Historically, a VPN connection required special, expensive VPN termination equipment located at each end of the connection, or required special client software to be installed and configured at the client machine. This equipment was rather expensive to acquire, and proved to be rather tedious to properly configure and hence costly to administer and maintain, particularly for those small to medium sized organizations that lacked adequate in-house technical support personnel.
In particular, at the remote client site, a so-called VPN terminator (also referred to as a “client-site VPN router”) was connected to a client PC to bi-directionally interface that PC to the VPN connection. This terminator provided layer 2 packet processing as well as appropriate packet encryption/decryption functionality. However, such a terminator, which included special-purpose software, was generally quite expensive to procure and needed to be installed and properly configured for its particular client PC—the latter entailing significant costs in both time and money. To mitigate the cost somewhat, various currently available PC operating systems (O/S's) now provide VPN support features, and, as an alternative, VPN vendors have built client VPN software that runs on the client machine and interacts with that vendors' own VPN server or with VPN servers from other vendors. Such client VPN software has been built to work with conventional PC O/S's such as Windows 98, Windows NT, Windows 2000, etc. However, PC O/S-based or client software based VPN support requires considerable packet processing (e.g., for packet encapsulation and disassembly, and cryptographic processing), which disadvantageously imposes a significant processing burden on the PC—though this burden may be acceptable for a home PC with a relatively light processing load, rather than a remote PC connected to an office network.
Furthermore, VPN services must be very secure. Unfortunately, until rather recently such PC O/S-based VPN support used a rather small key size, such as 40-bits, which generally does not provide sufficient security against third-party intrusion. While relatively new PC-based operating systems have become available that exhibit significantly increased VPN security, through use of triple DES and IPsec features—such as Microsoft Windows 2000 O/S (“Windows 2000 ” is a trademark of the Microsoft Corporation of Redmond, Wash.), this support still presents a considerable processing load to the PC; hence, denigrating PC performance, specifically processing throughput.
Moreover, such PC operating systems, whether those exhibiting increased VPN security or not, still do not provide requisite reliability.
As such, to provide VPN connectivity with required levels of security and reliability without imposing an undue processing load on the client PC, use of a separate dedicated client-site VPN terminator—even in view of its expense—is still strongly favored in practice.
Not only is expensive, specialized VPN equipment required at the client site (or alternatives such as OS-based VPN support or client software packages, both with their accompanying problems, need to be used), but it is also necessary, to an even greater extent, at the LAN (central) site. At the LAN site, VPN support requires installation and configuration of an office-site VPN router. Office-site routers are considerably more expensive than client-site VPN routers for the simple reason that the processing circuitry in the former, which implements the necessary cryptographic and packet processing operations, is sized based on a number of users that need to be simultaneously supported. Each user is allocated a certain slice of the available processing capacity. Even if such a router is sized to support just a few simultaneous remote users on the LAN, its cost can easily amount to several thousands of dollars, with the cost rapidly escalating as user load and hence necessary processing capacity of the VPN router increased. Recently, server operating systems, such as the Microsoft Windows 2000 server O/S, have become available that incorporate multi-user VPN support with sufficient security features; however, such support drains considerable processing resources from the server and still is insufficiently reliable. Moreover, if such a server O/S-based approach is used, counterpart client-site software, such as the Windows 2000 O/S, must be installed and properly configured on each client PC, which, if a large number of remote users exists, can be rather expensive and time consuming.
Therefore, in view of the relatively high cost involved, most small to medium sized organizations were and continue to be unable to afford the use of VPN connectivity, thus precluding themselves from providing secure remote office access to their internal networks and various business efficiencies and productivity increases that could have gained thereby.
A further, though totally different approach, evolved in the art for providing remote connectivity to an office LAN. This approach, predicated on an “application service provider”(ASP) model, involves installing specialized server software, such as “Metaframe” software available from Citrix Corporation, in the network server and an “ICA” client program in each client PC. Through the Metaframe program, the network server situated on the LAN would function as an ASP by hosting multiple virtual sessions of a given application program executing on the server, in effect implementing multiple virtual machines, to various different remotely located client PCs. Each remote client, running the ICA client program, would access, over, e.g., a WAN connection, a desired thin-client application hosted at the LAN-based server and establish a separate application session. The ICA client would communicate mouse clicks and keystrokes entered by a user stationed at the client PC, over the WAN connection, to the Metaframe program executing in the server which, in turn, would provide screen shots back to the client PC for local display to a user stationed thereat. This information would be carried between the client and server using an “ICA” protocol.
As PC manufacturers began equipping their PCs with client web browsers as standard issue software as well as users downloading such browsers for free from various software manufacturers, the Metaframe program evolved to permit remote browser-based web access, with the ICA client being replaced by the use of a resident client browser in the PC.
The concept of providing multiple virtual machines is also provided through “Windows Terminal Services” (WTS) software currently available from the Microsoft Corporation (“Windows” is a trademark of the Microsoft Corporation) for Windows NT 4 and Windows 2000 server operating systems, with client-server communication of screen shots, keystrokes and mouse clicks being carried to and from WTS using “RDP (‘Remote Desktop Protocol’ defined by Microsoft Corporation and based on the ANSI T.128 standard)”, rather than an “ICA” protocol. Again, WTS, like the Metaframe program, still carries a considerable processing burden.
Unfortunately, with this ASP-based approach, the client PC did not appear as if it were connected to the LAN. As such, while this approach did allow remote application execution, it did not accommodate remote access of other essential office network-based functionality, such as file sharing and e-mail. Hence, this approach was seen as being rather “one-sided”.
The art supplemented this ASP-based approach by incorporating a VPN (layer 2) connection between the LAN and client PC. This, in turn, provided added client functionality inasmuch as the client PC appeared as though it was on the remote LAN. However, this approach not only proved to be rather inconvenient to use but also, due to its VPN connectivity and for the reasons set forth above, rather expensive.
Specifically, a VPN server was connected to the LAN and a VPN router (or VPN terminator) was connected to each client PC, or each client PC used OS-based VPN support, or special client software had to be installed on each PC. The Metaframe program or WTS executed on the server which provided access, through a client browser or a special client application program, to a server-hosted virtual application session. By virtue of the VPN connection, the user at the client PC could remotely execute server-hosted thin-client applications, with the client PC appearing as if it were directly connected to the LAN. Unfortunately, this approach, being hampered by the constraints of the Metaframe software or WTS, only accommodated thin-client applications through the browser, and hence was just as “one sided”. No other network functionality, such as e-mail or shared file access, was accommodated through the browser; hence, this approach proved somewhat inconvenient to use. Moreover, the high cost of the associated VPN client-site and office-site servers principally dissuaded many small to medium size organizations from using this approach.
To off-load some of the processing burden from the LAN server running WTS, a two-tier approach recently appeared in the art through which a specialized processing system was inserted between the server and a WAN connection. This processor converted RDP packets associated with WTS into AIP packets (AIP is a proprietary protocol owned by Tarantella Inc. of Santa Cruz, Calif.) or to some other less bandwidth-intensive protocol and conducted client application communication (screen shots, keystrokes and mouse clicks) with the far-end client PC through either of the latter protocols. ICA provides similar bandwidth conserving functionality. Alternatively, communication in native RDP may be used instead. In any event, the client PC interacted with the processing system through either a specialized client application program or a web browser executing an appropriate JAVA applet (“JAVA” is a trademark of Sun Microsystems, Inc. of Palo Alto, Calif.). While this scheme relieved some of the load on the server, it still suffered the same deficiency as an ASP approach: it was not integrated and thus failed to provide through one single user interface, such as a browser, all the functionality which that user would have if his(her) client PC were directly connected to his(her) office LAN.
In view of the increasing costs of software acquisition, client installation and maintenance of client application programs, internally centralized ASP-based remote application hosting may well become an attractive alternative for business users.
However, adequate security remains a concern, particularly for small to medium size businesses that seek to implement an ASP-approach using the Win 2000 O/S or similar system. In that regard, WTS provides cryptography, though at a 168-bit level, through use of a symmetric key. While each RDP message from a network server to a remote client is sufficiently encrypted by WTS to preclude its brute-force cryptanalysis, shared symmetric keys are vulnerable to third party discovery for the simple reason that the secret key has to be distributed to the parties using it, and thus can be obtained by a malicious party. Since the Windows 2000 WTS approach does not involve the use of certificates, it is vulnerable to “man-in-the-middle” attacks from malicious parties that have obtained the symmetric key. In symmetric-key cryptography, both sides, here being the remote client PC and the server, utilize the same key. As such, if a third-party interloper, a so-called “man in the middle” that had previously obtained the symmetric key, were to intercept communications, that party through its computer, could pose as the server to the client machine, and as the client to the server machine. However, that party would thus be privy to all communications attempted between the client and the server, and thus have access to information that could be highly proprietary. That party could readily decrypt each message it received from one end and then alter the message contents as it saw fit, and transmit a modified message to the other end, thus potentially causing considerable mischief. Since WTS provides no effective protection to so-called “man in the middle” attacks, inasmuch as its symmetric key scheme does not involve the use of certificates and public keys cryptography, use of WTS under the WIN 2000 O/S is still not viewed by many organizations as offering a sufficiently attractive or secure solution to properly support such centralized thin-client application program hosting.
Additionally, network faults can and do occur. However, we believe that conventional network management schemes, as conventionally taught in the art, would be rather problematic when used with an office LAN that supports web-based remote user connectivity, and particularly so if network maintenance and management responsibility over that LAN is to be out-sourced, for reasons of economy—as would exist in many organizations—to a third-party vendor. Remote network management, through a centralized location, would be cost-effective provided the scheme chosen to do so could simultaneously monitor and manage a relatively large number of different LANs likely spread over a wide geographic area.
In particular, for some time, network management has been provided through use of the simplified network management protocol (SNMP). Through this protocol, network routers and other network equipment residing on a network could receive configuration information from and report internal alarm conditions to an SNMP management station connected to that network. In that regard, if a fault occurred within, e.g., a router, then that device could send an SNMP message to its management station in order to report that fault. Based on the specific information conveyed, a technician or other field-service personnel could diagnose, repair or replace that particular router, thus eliminating the fault and restoring the network to proper operation. Unfortunately, SNMP has historically provided inadequate security for its reporting messages. Moreover, in using relatively complex network equipment, it would often be rather helpful, whenever that equipment reports a fault, to establish an interactive session with that equipment and, through that session, download a piece of diagnostic software to that equipment and instruct that equipment to execute it and then report back the results, and based on those results, download and execute other software and so forth in an effort to fully diagnose and correct that fault. Unfortunately, SNMP, given its reliance on user datagram protocol (UDP) messaging, could not meet this need. In that regard, SNMP was primarily intended to handle relatively simple query-response type interactions between network devices and SNMP management stations. As such, SNMP is not conversational in nature and is also not session-oriented. Further, SNMP does not readily scale upward inasmuch as necessary hardware and other network infrastructure that would support its scalability, particularly with proper security, does not appear to commercially exist as yet. In that regard, large SNMP networks are typically partitioned in a predefined manner into much smaller sections through use of a separate corresponding SNMP management station assigned to each section. UDP SNMP messages from these sections are then often simply coalesced together, through higher level SNMP management devices, to generate a network status report. Thus, readily supporting large numbers of network devices using SNMP management tends to be cumbersome and expensive. Also, present SNMP-based schemes are readily susceptible to third-party intrusion.
While use of SNMP may be satisfactory for a single, well-defined LAN, even a large relatively static LAN with a known architecture, SNMP can not accommodate simultaneous centralized network management of large numbers of diverse LANs. In that regard, a single integrated SNMP network spread across all the LANs would be extremely difficult to configure and maintain, and quite costly to implement. Furthermore, if network support is out-sourced to a third-party vendor—particularly involving separate LANs existing over a large, geographically dispersed area, then the Internet becomes an ideal vehicle to connect a centralized management site at the vendor to each of these networks. Unfortunately, the weak security of SNMP messaging does not lend itself to carriage over a publicly accessible network, such as the Internet; thus, frustrating any provision of centralized, simultaneous out-sourced management of large numbers of remote LANs.
Therefore, a need exists in the art for a technique, specifically apparatus and methods for use therein, that provides secure, but integrated network functionality through a remote WAN connection between a remote client PC and a server based on an office LAN. Such a technique should provide all network functionality, including, e.g., thin-client application program hosting, file sharing and e-mail, through a single, commonly available user interface, such as a web browser, as if that client PC were connected directly to the LAN. The security should be such as to substantially eliminate potential “man in the middle” attacks or other such third-party intrusions. Furthermore, through such a technique, the client PC should appear as if it were directly connected to the LAN.
Furthermore, such a technique should permit centralized, simultaneous and remote management of large numbers of LANs in a manner that is highly secure to a level sufficient to permit network management messages to be carried over the Internet (or other publicly accessible network), session-oriented and readily scalable.
While such a technique could utilize a VPN connection, it should function with preferably far less costly alternatives, such as interacting directly with transport schemes such as DSL (digital subscriber line) or other relatively low-cost, high-speed digital access modalities. Also, such a technique should be remotely administered and supported, particularly when employed in those organizations which can not afford to maintain adequate in-house computer support capabilities.
Such a technique, were it to exist, would likely be very attractive to many organizations, including small and medium sized businesses: (a) to permit effective, readily-scalable but highly secure, internal ASP-based (centralized) thin-client application program hosting for remote client connectivity, with resulting cost savings to those organizations in terms of application procurement through centralized administration and maintenance of those application programs as well as centralized and remote network monitoring and management, and (b) through its use, to yield increased efficiency and productivity by providing remote access for individual users to all their office network-based functionality.